1. The Field of the Invention
The present invention relates to electronic messaging, and more specifically, to delegating certificate validation from an end-user computer system to a trusted intermediary computer system.
2. Background and Relevant Art
Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, and database management) that prior to the advent of the computer system were performed manually. More recently, computer systems have been coupled to one another to form computer networks over which the computer systems can communicate electronically to share data. As a result, many of the tasks performed at a computer system (e.g., accessing electronic mail and web browsing) include electronic communication with one or more other computer systems (e.g., via a local area network, a wide area network, and/or the Internet). For example, the path traveled by an electronic mail message transferred from a sending entity to a receiving entity can include a number of different computer systems connected to a number of different computer networks.
An electronic mail message is typically generated by a sending entity at a sending computer system and includes electronic data that is addressed to one or more recipient entities. When the sending entity is satisfied with the content of the electronic message, the sending entity “sends” the electronic message. Sending an electronic message causes the electronic message to be transferred from the sending computer system (e.g., the sending entity's personal computer) to a sending mail server (e.g., at the sending entity's Internet Service Provider). Subsequently, the electronic mail message is further transferred from the sending mail server (e.g., over the Internet) to one or more receiving mail servers (e.g., at the recipient entities' Internet Service Providers) that correspond to the one or more recipient entities.
From time to time, a recipient entity can use a receiving computer system (e.g., the receiving entity's personal computer) to access electronic mail messages stored at a receiving mail server. A recipient entity enters credentials (e.g., electronic mail address and password) at the receiving computer system that are then transferred from the receiving computer system to the receiving mail server. When appropriate credentials are received at the receiving mail server, the receiving mail server transfers electronic messages corresponding to the recipient entity's electronic mail address to the receiving computer system. The receiving entity can then view the transferred electronic messages at the receiving computer system.
Communication links that connect computer systems involved in the transfer of electronic mail messages often exist in a web configuration (e.g., the Internet), where any one of a number of different combinations of communication links can be used for transferring an electronic mail message between two computer systems. This is beneficial as it provides some level of redundancy. That is, when one communication link fails, a number of other communication links may still provide communication between computer systems. To further facilitate efficient electronic communication between computer systems, many communication links, especially those on the Internet, are made publicly available. That is, if a computer system is able to access such a network, the computer system inherently has access to all the public communication links connected to the network. This promotes free flow of information between computer systems (and their users) without significant restraints of the type of data that can be transferred in an electronic mail message.
Due at least in part to the ease and efficiency of electronic mail, the number and diversity of entities that use electronic mail is quite large. However, the accessibility of public communication links provides a malicious user with an avenue to intercept and alter an electronic mail message as the electronic mail message is transferred between computer systems. In some cases, such as, for example, when transferring news items or other public information, the risk may be tolerable since this type of data is already public and verifiable via other mechanisms. However, in a large number of other cases, such as, for example, when sending financial or sensitive personal information, the risk of unauthorized alteration of an electronic mail message may be unacceptable. Further, there is always some risk of a malicious user impersonating (e.g., by spoofing a domain name) a sending entity to make an electronic mail message appear as if it were sent from the sending entity (when in fact the malicious user sent the electronic mail message).
Accordingly, a sending entity can attach a digital signature to an electronic mail message. A digital signature can be processed by a receiving entity to verify that the contents of an electronic mail message have not been altered and to prove the sending entity M sent the electronic mail message. Digital signatures can be created and verified using public key cryptography, which utilizes mathematically corresponding (but different) keys to create and verify digital signatures. One of the keys, commonly referred to as a “private key”, is known only to the signer and is the key used to create a digital signature. The other key, common referred to as a “public key”, is more widely known and can be used to verify a digital signature created from a corresponding private key. Although keys of a public/private key pair are mathematically related, it is computationally infeasible to derive a private key from a corresponding public key.
A hash function is also typically used when creating or when verifying a digital signature. A hash function is an algorithm that creates a digital representation or “fingerprint” of an electronic mail message, in the form of a hash value. A hash value is usually much smaller than the electronic mail message but nevertheless is essentially unique to the electronic mail message. Hash functions allow modules that create and verify digital signatures to operate on smaller and predictable amounts of data, while still providing evidentiary correlation to the contents of an electronic mail message.
To generate a digital signature for an electronic mail message, a sending computer system creates a sending side hash value of the electronic mail message. The sending computer system then encrypts the sending side hash value with a sending entity's private key. On the other hand, to verify a digital signature, a receiving computer system creates a receiving side hash value (using the same algorithm used by the sending computer system) of the electronic message. The receiving computer system decrypts the digital signature with the sending entity's public key. This decryption reveals the sending side hash value. When the sending side hash value and the receiving side hash value match, there is a significantly reduced chance that the electronic message was altered during transmission or that the sending entity is being impersonated.
Thus, to verify a digital signature, a receiving entity must have access to a sending entity's public key and have some assurance that it corresponds to the sending entity's private key. However, a public/private key pair has no intrinsic association to a particular entity; it is simply a pair of numbers. Accordingly, a receiving entity must also have access to some reliable information that associates an entity with a public/private key pair. In networks with many-to-many architectures, such as, for example, the Internet, where a significant number of transactions can occur through electronic mail, dissemination of this reliable information can be problematic.
Accordingly, many entities rely on trusted third parties, commonly referred to as “certificate authorities”, to issue and associate an entity with a specific public key (and thus, although not divulged to potential recipient entities, also the corresponding private key). To associate an entity with a public/private key pair, a certificate authority issues a certificate, an electronic record that associates an entity with a public key. Thus, a certificate effectively binds a public/private key pair to a particular entity. A recipient of a certificate can use the public key listed in the certificate to verify that a digital signature was created with a corresponding private key (and thus also verify a sending entity). When a public key from a certificate is successfully used to verify a digital signature, a recipient entity has increased assurance that the corresponding private key was held by the entity named in the certificate.
To assure both the integrity and authenticity of a certificate, the issuing certificate authority digitally signs the certificate. The certificate can then be verified using the public key of the certificate authority, as provided in a certificate issued and signed by another certificate authority. When appropriate, the integrity and authenticity of the certificate from the other certificate authority can be verified using the public key of the other certificate authority, as provided in a certificate issued and signed by yet another certificate authority. Accordingly, to verify a digital signature, a recipient entity may verify a number of certificates in a certificate chain, until the recipient entity is satisfied as to the integrity and authenticity of the electronic mail message (e.g., when a root certificate indicates that a certificate can be trusted).
Verifying a digital signature can include verifying certificates in a hierarchical arrangement of certificate authorities (e.g., of an X.500 directory). In such an arrangement, higher level certificate authorities provide certificates that can be used to verify the certificates of lower level certificate authorities. At the top of the hierarchy can be a certificate authority (a root certificate authority) that is explicitly trusted. Accordingly, a verifying entity can “walk a chain” of certificate authorities from a lower level certificate, up a hierarchy, until the verifying entity validates a self-signed certificate (the root certificate).
When issued, a certificate typically includes a period of validity, before and after which the certificate is typically not considered valid by the issuing certificate authority. Thus, a receiving computer system can indicate to a recipient entity when a sending entity's certificate is considered not valid. Before a period of validity begins or after a period of validity expires, a verifier has decreased assurance that a corresponding private key held by the sending entity can be trusted.
Further, before expiration of a certificate, it may be that a corresponding private key is compromised or that a certificate authority decides a corresponding entity can no longer be trusted. For example, a malicious user may gain access to an entity's computer system and access (e.g., export) any private keys stored at the computer system. Thus, there is always some possibility of receiving a digital signature associated with a non-expired but compromised certificate. A malicious user could impersonate an entity using a C compromised private key corresponding to the compromised certificate. Unfortunately, based solely on information contained in a non-expired certificate, a receiving entity has no way to know if the trustworthiness of the non-expired certificate has been compromised.
Accordingly, a certificate authority may maintain a Certificate Revocation List (“CRL”) that, depending on the desired configuration, includes non-expired certificates that have been revoked (or suspended) by the certificate authority. A recipient computer system can access a CRL (e.g., by downloading the CRL) for a certificate authority to determine if a certificate issued by the certificate authority has been revoked. Thus, upon receiving a digitally signed electronic mail message, a receiving computer system can check an appropriate CRL to determine if a certificate corresponding to the sending entity has been revoked.
The receiving computer system typically checks an appropriate CRL (as opposed to offloading the checking to an intermediary computer system) so as to mitigate the possibility of CRL data being intercepted and altered. Further, when a certificate issued from an intermediate certificate authority to an issuing certificate authority is compromised; all the certificates issued by the issuing certificate authority are also considered compromised. Thus, similar to validation of a certificate, a receiving entity may have to check a chain of CRLs to determine if a certificate has been compromised. That is, each CRL is signed by an issuer certificate. To check the validity of the issuer certificate, its parent issuing certificate and CRL must be also validated. This continues until a root certificate is reached that is explicitly already trusted by the receiving user.
The list of certificates revoked by a certificate authority can change, such as, for example, when additional certificates are revoked and/or revoked certificates expire. Accordingly, at a specified time interval selected by the certificate authority, the certificate authority can publish a new CRL. However, since new CRLs are published at specified time intervals (as opposed to continuous updates), there is always some chance that a revoked certificate is used after it has been revoked but before the revocation has been published in a CRL. When the specified time interval is large and/or a certificate authority manages a significant number of certificates, the chance of a revoked certificate being used before publication in a CRL increases. Further, even if a certificate authority were to publish a new CRL at the precise time each certificate is revoked, the certificate authority may have no way to control the frequency with which computer systems that use the CRL are updated.
Further, depending in part on the number of certificates issued and the security implemented by a certificate authority, a CRL can become relatively large, for example, in the hundreds of megabytes. Thus, frequently publishing a new CRL can consume a significant amount of computer system and bandwidth resources at a certificate authority. Further, checking a CRL can consume substantial computer system and bandwidth resources of a computer system attempting to validate a digital signature. During validation of a signature, the computer system checks a CRL to determine if a certificate corresponding to a sending entity has been revoked. When a CRL is relatively large, the computer system can spend a significant amount of time and resources accessing and scanning a CRL. Further, the computer system may be required to access and scan a number of CRLs corresponding to various levels of certificate authorities in a hierarchy. To alleviate this issue, newer certificate authorities may issue a smaller “delta” CRL that contains only serial numbers of certificates revoked since the last “full” CRL was issued.
However, even with smaller delta CRLs, the size of CRLs essentially prevents constrained resource devices and devices that operate in low bandwidth environments from verifying digital signatures. For example, a mobile phone or pager may altogether lack the resources needed for downloading and/or a scanning a 7 MB CRL. Further, for a computer system to validate a digital signature, the computer system must be configured with the appropriate modules and protocols (e.g., Lightweight Directory Access Protocol). When an organization includes a number of computer systems, configuration of validation modules and protocols can consume a considerable amount of time. Further, many public computer systems that provide Web based access to electronic mail, such as, for example, at public kiosks, may not include appropriate modules and protocols for validating digital signatures. Even when a public computer system does include appropriate modules and protocols, the public computer system may trust a set of incomplete root certificates or may trust certificate authorities that are otherwise unacceptable to an organization. Accordingly, a user accessing electronic mail through a public computer system may have no way to reliably validate a digital signature. Therefore more efficient systems, methods, computer program products, and data structures for validating a certificate would be advantageous.